In software project management, measurements are the quantitative basis for making informed decisions. They allow project managers to track progress, ensure quality, and predict future outcomes rather than relying on gut feeling.
Measurements are typically categorized into three main levels:
1. The Measurement Hierarchy
Understanding the difference between metrics and indicators is crucial for effective management.
- Measure: A direct observation of a physical quantity (e.g., number of errors found).
- Metric: A quantitative measure of the degree to which a system, component, or process possesses a given attribute (e.g., errors found per thousand lines of code).
- Indicator: A metric or combination of metrics that provides insight into the software process, project, or product (e.g., an increasing error rate indicating a decline in code quality).
2. Key Categories of Measurement
Process Metrics
These focus on the long-term effectiveness of the software engineering process. The goal is to improve the overall “health” of the development lifecycle.
- Defect Removal Efficiency (DRE): Measures how many bugs were found before the software was released versus after.
- Cycle Time: The time it takes to move a task from “In Progress” to “Done.”
- Velocity: In Agile, the amount of work a team can complete in a single sprint.
Project Metrics
These are used by project managers to monitor the status of a specific ongoing project and minimize risk.
- Cost and Schedule Variance: Tracking actual spending and timelines against the original baseline.
- Resource Utilization: Monitoring how effectively team members and hardware are being used.
- Scope Creep: Measuring the number of new requirements added after the project started.
Product Metrics
These focus on the characteristics of the software itself.
- Complexity: Often measured via Cyclomatic Complexity, which counts the number of linearly independent paths through the code.
- Maintainability: How easy it is to modify the software.
- Reliability: Measured by Mean Time To Failure (MTTF).
3. The GQM Paradigm (Goal-Question-Metric)
A common mistake is measuring everything and analyzing nothing. The GQM approach ensures that every measurement has a purpose:
- Goal: Define what you want to achieve (e.g., “Improve software quality”).
- Question: Ask questions that define the goal (e.g., “How many bugs are reaching the end-user?”).
- Metric: Identify the measurements needed to answer those questions (e.g., “Number of post-release defects”).
4. Software Quality Metrics
Quality is often the most difficult aspect to quantify. Common metrics include:
| Metric | Purpose |
| Defect Density | Number of defects per unit size (e.g., per 1,000 lines of code). |
| Code Coverage | Percentage of code executed during automated testing. |
| Customer Satisfaction | Often measured via Net Promoter Score (NPS) or surveys. |
| Technical Debt | The estimated effort required to fix “quick and dirty” code. |
Measurement should never be used to punish team members. If a metric becomes a target for performance reviews, people may “game the system” (e.g., writing more lines of code just to hit a quota), which destroys the accuracy of the data.